Method of deployment for concurrent execution of multiple versions of an integration model

ABSTRACT

A method of executing plural versions of business process management software on plural integration servers. A plurality of components are defined. The components can include executable process logic of a business process and at least one port defining a standard representation of an external interface of said component. Connections between ports of desired components are also defined. The components and connections are stored in a repository as a set objects and the set of objects is loaded as a first version in a first runtime environment by configuring run time properties of the set of the objects. After modification of the set of objects, the modified set can be loaded as a second on a second server by configuring run time properties of the set of the objects as modified.

RELATED APPLICATION DATA

[0001] This application is a continuation-in-part of U.S. applicationSer. No. 09/984,978 filed on Oct. 31, 2001 and entitled , Method ofDeployment for concurrent execution of Multiple Versions of anIntegration Model on an Integration Server, which is acontinuation-in-part of U.S. application Ser. No. 09/823,953 filed onMar. 30, 2001 and entitled Versioning Method for Business ProcessModels, the disclosures of which are incorporated herein by reference.This application is also a continuation-in-part of U.S. application Ser.No. 09/984,977, filed on Oct. 31, 2001 and entitled Integrated BusinessProcess Modeling Environment and Models Created Thereby, the disclosureof which is also incorporated herein by reference.

BACKGROUND

[0002] The present invention relates generally to methods for executingprograms, such as those represented by business process models. Moreparticularly, the present invention relates to a method that facilitatesconcurrent execution of multiple versions of a business process.

[0003] An integration server, or business process management system, isa computer system that executes automated and/or manual businessprocesses. Business processes are steps that a business undertakes toaccomplish some objective, such as hiring an employee, processing anorder, or procuring components required for production. As an example,consider the case of a retail business. For this type of environment, abusiness process might track customer orders. Business processmanagement systems are typically designed in a way that makes theirbehavior easy to customize. This allows the same underlying system to bedeployed in a range of different environments and with differentsoftware applications.

[0004] To provide this type of flexibility, some integration servershave adopted a model-driven approach which describes business processesin terms of business process models. A business process model can bethought of as a formal definition of a business process and can beexpressed in a high-level graphical modeling language such as UML(Uniform Modeling Language). Business process models define the runtimebehavior of business process instances using state diagrams. The statesappear as graphical objects and the connections between states are knownas transitions. An instance of the executing business process willtraverse transitions and move between states in response to events.Events are notification within the model that something has happened inthe real world. Customers placing orders and customers canceling ordersare two examples of events. The model-driven approach can be powerfulbecause it facilitates creation and manipulation of business processeswithin a graphical environment. This allows designers to create businessprocess models in a manner similar to operating a typical drawingprogram, without concern for the underlying computer code. In this way,model-driven business process management systems greatly reduce the needfor highly skilled programmers. Recently, the model-driven approach hasbeen extended to the integration of various applications. For example,the BusinessWare™ modeling environment sold by Vitria™ Technology, Inc.permits modeling of the integration of applications in a graphicalmanner.

[0005] The concept of “value chains,” i.e., a series of businessactivities that create value, has become a useful paradigm for analyzingand improving the efficiency of businesses. Such activities includebusiness processes, such as order entry, shipping, invoicing, CRM, andthe like. Value chains are dependent on the internal business processesof a company, the business processes of trading partners, such assuppliers, and the relationship between the company and tradingpartners. It has become popular to experiment with and change valuechains to optimize profitability. Such change requires modification ofbusiness processes and deployment of a modified version of a businessprocess model.

[0006] Unfortunately, in operational business process managementsystems, it may be undesirable or impossible to halt the system toupdate a business process. Even in cases where this is possible,shutdown may still be difficult if the system is populated withinstances created using the old version of a business process. Forexample, the system may contain pending orders , represented byinstances, at the time of shutdown for change to a new version. As aresult, shutdown often requires that the system be maintained in apartially operational configuration (e.g., running but not accepting neworders) until all instances of pending orders have been fully processed.

[0007] Further, it is well known to use “load balancing” to increaseperformance and scalability of software programs. In known loadbalancing schemes, processing activity is distributed across a computernetwork so that no single device is overwhelmed. For example, busy Websites typically employ two or more Web servers in a load balancingscheme; each server running identical software programs. If one serverstarts to get swamped, requests are forwarded to the other. However,business process models and integration models include plural softwareprograms and various repositories and other resources, all configured ina specified manner for interoperability. An executing instance of abusiness process model or integration model is referred to as a“project” herein. The complexity of business process models andintegration models has rendered it difficult to load balance projects.The difficulty comes from having to manage the plurality of componentswithin a project. Load balancing may require one to replicate some orall of the components of a project. This is difficult to do, and hasbeen accomplished only through various ad-hoc mechanisms. For example isknown to utilize scripts to re-start all the components of a project.Such mechanisms are difficult to create and maintain and require a greatdeal of processing overhead.

SUMMARY OF THE INVENTION

[0008] An object of the invention is to facilitate running of multipleinstances of of business process integration applications respectivelyon plural integration servers. To achieve this an other objects, a firstaspect of the invention is a method of deploying multiple versions ofcomputer code for integrating business processes in plural integrationservers. The method comprises defining a project comprising a pluralityof objects, at least some of said objects including executable processlogic of a business process and at least some of the objects comprisingconnection information between business processes, storing the objectsas a set corresponding to an integration model in a repository to beexecuted in a runtime environment of the integration server, loading theset of objects as a first version of the project in a first runtimeenvironment of the integration server, and loading the modified set ofobjects as a second version of the project in a second integrationserver.

BRIEF DESCRIPTION OF THE DRAWING

[0009] The invention will be described through a preferred embodimentand the accompanying drawing, in which:

[0010]FIG. 1 is a block diagram of a computer architecture for use withthe preferred embodiment;

[0011]FIG. 2 is an example of an integration model created by thegraphical modeling module of the architecture of FIG. 1;

[0012]FIG. 3 illustrates a business process model of the example of FIG.2;

[0013]FIG. 4 illustrates the configuration display screen of thepreferred embodiment;

[0014]FIG. 5 illustrates the partitioning display of the preferredembodiment;

[0015]FIG. 6 is a flowchart of a deployment method of the preferredembodiment; and;

[0016]FIG. 7 is a flowchart illustrating the deployment steps of FIG. 6in detail.

GLOSSARY

[0017] The following description below uses terms of art which aredefined below:

[0018] Business Process Model—A state machine that models businessprocesses at a semantic level and defines an executable specificationfor the underlying business logic.

[0019] Channel—A connector component which models an asynchronouscommunication using the publish/subscribe paradigm.

[0020] Class—a modular object oriented unit of code.

[0021] Component—A reusable graphical representation of a businessprocess model or other system element. A component can represent abusiness process model, a transformation, a process query, or anotherintegration model and interacts with other components through a definedinterface.

[0022] Deployment—The physical arrangement and configuration of a model.

[0023] Instance—A particular execution of a business process model orintegration model.

[0024] Integration Model—A model that describes interactions betweenbusiness processes from a data flow perspective.

[0025] Java Virtual Machine (JVM)—An abstract computing machine, orvirtual machine, that provides a platform-independent programminglanguage that converts Java bytecode into machine language and executesit.

[0026] Lightweight Directory Access Protocol (LDAP)—A set of protocolsfor accessing information directories.

[0027] Model—A representation in a certain form that captures theimportant aspects of the thing being modeled from a certain point ofview and simplifies the rest.

[0028] Object—Generally, any item, or a graphical representation of theitem, that can be individually selected and manipulated.

[0029] Port—A representation of the set of interfaces a componentexposes.

[0030] Project—A set of objects that can be deployed as an instance of abusiness process model or an integration model.

DETAILED DESCRIPTION

[0031] In conventional systems, the knowledge of what comprises aproject is not captured for load balancing purposes by the designer ofthe project. The preferred embodiment addresses this problem byproviding the notion of a project within a component based integrationenvironment and then uses the notion of a project to parameterize aproject by exposing various configurable properties and leverage theparameterization for load-balancing.

[0032]FIG. 1 illustrates computer architecture 10 for developing,deploying, and executing integration models in accordance with apreferred embodiment. Business process systems, such as ERP system 12,CRM system 14, order processing system 16, and inventory system 18control associated business processes and are coupled to integrationserver 30 over a network or other communication channel. In addition,trading partner system 36, such as the integration server of a supplieror other external party, is coupled to integration server 30 over theInternet or other communication channel. Integration server 30 iscoupled to development server 40 and repository 48 through appropriatecommunication channels such as a local area network. Repository 48 isillustrated as a separate device but can be embodied within integrationserver 30 or development server 40. Repository 48 includes a storagedevice and can include processing logic as will become apparent below.

[0033] Development server 40 includes graphical modeling module 42, inthe form of software, which provides the process modeling environment,including a user interface, for configuring business process models andintegration models. Integration server 30 includes execution engine 32for executing an integration model after deployment. Integration modelsare executed by execution engine 32 by directing the flow of informationamong the underlying internal and external systems 12, 14, 16, 18, and36. After defining the business processes that need to be automated, adeveloper then creates visual models of those processes, and theintegration thereof, using a graphical interface. The resultingintegration model consists of plural components representing underlyingexecutable code for executing and integrating the various businessprocesses.

[0034] Integration server 30 also includes messaging module 34 whichserves as a messaging layer or infrastructure for execution engine 32and systems 12, 14, 16, 18, and 36. For example, an event-drivenpublish-subscribe methodology can be deployed via communicationschannels to transport information in a consistent format betweensystems. In the case of communication with external systems, messagingmodule 34 can transform data into standard formats, such as XML, EDI, orany other known or future protocols, and transport the data in anencrypted form over networks using standard protocols such as HTTP, FTPand SMTP. Integration server 31 can be similar to integration server 30and CRM system 15 can be similar to CRM system 14, as is described inmore detail below.

[0035]FIG. 2 illustrates a simple example of an integration modeldeveloped by modeling module 42. The integration model consists of orderprocess component 20 representing an underlying business process modelas discussed in detail below, order source component 50, and orderstatus component 60. Order source component 50 can represent an externalsystem of a trading partner or any other source of order information.Order status component 60 can represent a database file or any othersystem for recording and/or tracking order status. Order sourcecomponent 50 and order status component 60 can include transformationsthat serve to transform one data format to another to exchangeinformation between the systems represented by the components. Orderprocess component 20 has input port 22 and output port 24 associatedtherewith, order source component 50 has output port 54 associatedtherewith, and order status component 60 has input port 62 associatedtherewith. The appropriate ports are connected by lines, referred to as“wires” herein, which define the connections between ports. Specificallywires 70 and 72 couple the ports as illustrated. Ports are described ingreater detail below. All elements can be created, configured, andmanipulated through the user interface of modeling module 42 in agraphical manner, much the same as in a simple drawing program.

[0036] The business process model underlying order process component 20can also be created in a graphical environment using modeling module 42.FIG. 3 illustrates an example of such a business process model. Thebusiness process model consists of four states, start state 102, processorder state 104, update inventory state 106, and termination state 108.Transitions 110, 112, and 114 connect the states as illustrated.Transitions define the logic that is executed to move an instance of thebusiness process model from one state to the next state. Accordingly,transitions may have action code associated therewith. The action codecan be any code that can be executed directly, compiled, translated, orotherwise processed for execution. For example, the action code can be aJava object. An example of such action code, which records orderinformation to be processed, is below:

[0037] // record the order

[0038] myOrder.order(order)

[0039] CommonMessages.logGenericTrace (“Order”+myorder.oid( )+

[0040] “received from customer”+order.customer);

[0041] Returning to the integration model of FIG. 2, ports define astandard way to represent the external interface of components. Portsare used to communicate dataflow between components. The upstream portcomponent is defined as an output port and the downstream port componentis defined as an input port. Each port has underlying properties thatcan be assigned during integration model development and/or deployment.A property sheet can be accessed through the user interface of modelingmodule 42 by right clicking on the port component, selecting a commandfrom a menu, or the like. The properties associated with all components,and ports can be stored as objects in a directory structure inrepository 48, which is an LDAP directory in the preferred embodiment,as described below, for access by the runtime environment. Repository 48acts as a shared directory service that can be accessed remotely. When acomponent is created, code is automatically generated in correspondenceto the component for looking up connection information for each port ofthe component, including the port to which it is connected, the type ofthe port and how to connect to the port. At runtime, this code serves toidentify and bind the proper communication protocols.

[0042]FIG. 4 illustrates the configuration display of screen 200 forviewing the objects stored in repository 48. In the preferredembodiment, the objects are displayed in a directory tree structure inwindow 202. It can be seen that the objects are grouped in a logicalmanner. For example, the folder named “Part A” includes the objects fororder process component 20, the associated input port 22, and theassociated output port 24. Of course, all other objects corresponding toan integration model, and objects corresponding to other integrationmodels can be stored in repository 48 and displayed in window 202.However, in FIG. 4, such other objects have been omitted for clarity.Display window 204 displays a property sheet corresponding to thecurrently selected object in window 202. In this example, input port 22is selected and indicated by the user interface by shading. It can beseen that the property sheet includes the port name, the port direction,the port type, the kind of port, the transactions of the port, the typeof authentication, and the connections of the port. These properties canbe either selected by the model designer or automatically assigned bythe model configuration as described below.

[0043] The port name can be an arbitrary name assigned to the port todistinguish the port and its object from other ports and components. Thename can be selected by the designer or automatically assigned bymodeling module 42. For example, the ports can be numbered in order oftheir creation or position in the model. Also, the ports can named basedon the name of the component to which they are associated. For example,port 22 could be named “Order Process Input Port.” The directionindicates the direction of flow of data or events through the port. Thedirection can be assigned automatically by automation module 42 based onthe type of port and/or the connections which are defined by the wiresdescribed above. For example, input port 22 has a direction of “in”because, by definition, it is an input port.

[0044] The port type indicates the operation or event that passesthrough the port. For example, port 22 receives and event called“NewOrderEvent.” This event is defined by the event passing throughoutput port 54 connected to input port 22 by wire 70 (see FIG. 2). Theevent “NewOrderEvent” is an output event of the business process modelunderlying order source component 50. In this example, port 22 operatesin a synchronous mode and is coupled directly to port 54 by wire 70. Ifcommunication between ports is to be asynchronous, meaning that theports subscribe to a channel, que or the like and need not be ready toreceive an event when the event is created, the appropriate component,such as a channel component, will be inserted in the model between theports. The transactions of the port is “True” meaning that transactionscan be propagated across components by invocation. The authentication ofthe port is “Simple” meaning that only password security is applied. Inthe alternative, authentication can be complex and require acertificate, key, or the like. Also, the port is connected to Port 2,which is the port name assigned to output port 54 in this example. Thisconnection is automatically set based on the wires configured in theintegration model illustrated in FIG. 2.

[0045] Once the integration model is configured, it represents a logicaldescription of an application. Of course, to be executed, the model mustbe turned into a physical description that can be run in a run timeenvironment. The process of changing from a logical model to a specificphysical model is referred to as “deployment” herein. Deployment in thepreferred embodiment consists of deployment configuration, partitioning,packaging, and installation steps. Once the integration model is createdusing modeling module 42, the integration model can be deployed for atest environment or a production environment. Further, as will becomeapparent below, multiple versions, i.e., instances, of the integrationmodel can be deployed on respective servers to provide load balancingand redundancy.

[0046] Deployment configuration refers to the steps involved in fillingout unresolved component references including, component-specificproperties, security references, and environment properties.Partitioning deals with making the application run efficiently byplacing components on different machines on a distributed environment.Partitioning must take into account the network topology, as well ascharacteristics of the nodes on which components are partitioned.Specifically, partitioning refers to placing the component in a ‘home’node and server (channel server, web server or integration server) whereit is to execute. The node and server provide a deployable destinationwith a ready environment. Integration model components may bepartitioned onto integration server 30. Channels may be partitioned ontoa channel server. Partitioning allows for distribution of componentsacross multiple devices, i.e. nodes. Accordingly, the phrase“integration server” can refer to one node or a set of plural nodes.When multiple versions are said to execute on the “same integrationserver,” the versions run on the same node or the same set of nodes thatdefines the integration server. When multiple versions run on multipleintegration servers, the versions run on different nodes. Packagingrefers to how the components are organized into a unit fit fordistribution/execution. For example, the Java standard for packagingcomponents is a .jar (Java application resource) file, which can be usedwith the preferred embodiment.

[0047] Installation refers to how the files representing the solutionare actually moved to the target nodes. The deployment package can be ashared directory service in repository 48. Runtime components and toolscan all reference this location. Alternatively, the deployment packagecan be stored separately and extracted into repository 48 at a latertime. Startup refers to how the configured, installed application isactually executed in its target environment.

[0048] By selecting the partitioning tab of display 200 in FIG. 4, thedeployment display of FIG. 5 is called up. The deployment displayincludes window 206 which shows all deployable objects of an integrationmodel or plural integration models, some of which are omitted in FIG. 5for simplicity, in a directory tree structure. Also, window 208 showsall physical nodes, i.e. computers, directories, networks, or the likeof the physical distributed system, some of which are omitted in FIG. 5for simplicity, in a directory tree structure. The designer can selectan object in window 206 and a node in window 208 and press the “Add”button to partition the selected component to the selected node.Alternatively, a “drag and drop” interface can be used. The selectedcomponent object will be placed in the tree structure of window 208under the selected node. Component objects can be selected from window208 and the “Remove” button can pressed to un-partition the component.

[0049] A button or menu selection can be activated to create adeployment package, e.g. a .jar file, deployment descriptors, and anyother files needed for deployment. The deployment package can be storedin repository 48. Subsequently, error checks can be accomplished and thedeployment can be installed in the proper resources.

[0050]FIG. 6 illustrates the method of deploying plural versions of aproject in integration server 30 in accordance with the preferredembodiment. In the preferred embodiment, the executable codecorresponding to components is Java code and is stored as a plurality offiles each corresponding to a Java class. The designer can select a setof components to define a first version of a project, during deploymentdescribed above, which correspond to a first version of the integrationmodel to be deployed in step 400. In step 410, the selected files aredeployed into repository 30 and loaded in the manner described above ina first runtime environment. A second version of the project to bedeployed can be selected in step 420 and loaded as version 2 in a secondruntime environment of second integration server 31 in step 430. The setof components defining the first version of the project in 420 can bethe same as or modified with respect to the set of components definingthe second version of the project in step 410. For example the firstversion can be configured to communicate with CRM system 14 and thesecond version can be configured to communicate with CRM system 15.Integration server 31 can be similar to integration server 30 describedabove.

[0051]FIG. 7 illustrates the deployment steps 410 and 430 in detail. Instep 412, a custom loader is defined for version 1. A loader is a knownoperating system utility that copies files from a storage device,repository 30 in the preferred embodiment, to main memory where thefiles can be executed. A loader may also replace virtual addresses withphysical addresses for the particular runtime environment. The Javadomain includes a class loader that dynamically loads classes by callingthe public loadClass( ) method. However, in the preferred embodiment acustom loader is defined. For example, the method URLClassLoader( )canbe used to load only classes having specific URLs, i.e. desired classes.Each URL can represent a file of a component selected in step 400. Instep 414, the custom class loader is executed to place the desired Javaclass files in repository 30 for execution. Properties and otherinformation can be loaded based on version information of the objects.In step 416, the loaded classes and other information are loaded in aJava Visual Machine in integration server 30 and executed.

[0052] Similarly, in step 432, a custom class loader is defined forversion 2. In step 434, the custom class loader is executed to place thedesired Java class files in repository 30 for execution. In step 436,the loaded classes and other information are loaded in a the JVM inintegration server 30 and executed. The JVM defines a “machine within amachine” and mimics a real processor, enabling the two versions of Javabytecode to be executed independently of one another regardless of theoperating system. Accordingly, various versions of an integration modelcan be created and simultaneously deployed and executed on separateintegration servers. The versions can be executed concurrently on therespective integration servers. Note that different versions can be theresult of a change to a specific component or components, addition ofnew components, or the change in structure of an integration model.Further, dependent versions can be isolated in the manner describedabove.

[0053] The separation between logical and physical in the preferredembodiment also facilitates creation of reusable project components.While the concept of reusable components is well known generally, thepreferred embodiment permits a more flexible approach to reusablecomponents at a project level. For example, a model designer can createan item that is desirable for reuse in the manner described above. Theitem can include nested child components, each representing anunderlying business process. More specifically, the item to be used as areusable component can be of any granularity, such as a top levelintegration model or a business process model. The designer selects theitem using the user interface and is requested to enter an item name anddestination file. A wizard can allow the designer to supply values for adestination package name, a short description, icon images to beassociated with the item in the graphical environment, a customizerclass, a version name or number, and any other parameters of theresulting object.

[0054] The user interface will then display a collection of theproperties (including hidden and read only properties) that representall the properties of all the elements in the hierarchy beneath theindicated item. For example, the elements can be code objects, such asJava objects. For each property in the collection, the designer canchoose to either keep the value of the property or to turn the propertyinto a property on the resulting reusable component. This permits thedesigner to parameterize the component for ease of configuration. Forproperties that will be turned into parameters on the resulting reusablecomponent, the designer may provide a default/initial value anddesignate the property as being read only, hidden and/or expert. A new.jar file is then generated for the object. The .jar file is created bygenerating source code file that implements the properties as describedby the designer. This class will implement a port interface and a secondclass holding the new object's description will be generated. The liveinstance of the item that the designer initially selected can beserialized to a .ser file using standard Java serialization. The twosource files can be compiled to .class files using a Java compiler. Thena JAR manifest will be computed. The java source files, theircorresponding .class files, the .ser and the manifest file can bearchived into JAR format and the temporary file removed from thedesigner's system. The values of exposed parameters of a component canbe changed when deploying a project on an integration server toconfigure the project for the integration server or in any other manner.

[0055] It can be seen that the preferred embodiment provides anintegrated modeling environment in which the business process logic isseparated from back-end integration and system issues. This separationallows the business analyst, not the programmer, to focus on theimportant work of designing business rules to solve specific businessissues. Such separation also enables deployment of various versions ofan integration model concurrently on the different integration servers.

[0056] As described above, the repository serves as a shared directoryservice and stores all project information. Accordingly, to undeploy aproject, the user merely designates the project and the developmentserver can remove all project information from the repository.Accordingly, undeployment can be accomplished efficiently andcompletely.

[0057] The invention can be implemented on any device, such as apersonal computer, server, or any other general purpose programmablecomputer or combination of such devices, such as a network of computers.Communication can be accomplished through any channel, such as a localarea network (LAN), the Internet, serial communications ports, and thelike. The communications channels can use wireless technology, such asradio frequency or infra-red technology. The various elements of thepreferred embodiment are segregated by function for the purpose ofclarity. However, the various elements can be combined into one deviceor segregated in a different manner. For example, software can be asingle executable file and data files, or plural files or modules storedon the same device or on different devices. Any protocols, data types,or data structures can be used in accordance with the invention. Theinvention can be used to design, create, manipulate, test or use anybusiness process model or integration model and can be used incombination with amy type of system for affecting business processes.Any appropriate user interface can be used to design, create, andmanipulate models. The underlying code can be written in any language,such as Java, or the like.

[0058] The invention has been described through a preferred embodiment.However, various modifications can be made without departing from thescope of the invention as defined by the appended claims and legalequivalents thereof.

What is claimed is:
 1. A method of deploying multiple versions ofcomputer code for integrating business processes in plural integrationservers, said method comprising: (a) defining a project comprising aplurality of objects, at least some of said objects including executableprocess logic of a business process and at least some of the objectscomprising connection information between business processes; (b)storing the objects as a set corresponding to an integration model in arepository to be executed in a runtime environment of the integrationserver; (c) loading the set of objects as a first version of the projectin a first runtime environment of the integration server; and (d)loading the modified set of objects as a second version of the projectin a second integration server.
 2. A method as recited in claim 1,further comprising modifying the set of objects after said step (c) andbefore said step (d).
 3. A method as recited in claim 2, wherein saidset of objects is stored as a component having a parameter set includingvariables that can be changed in value to configure the component.
 4. Amethod as recited in claim 2, wherein said modifying step compriseschanging a value of at least one of said variables.
 5. A method asrecited in claim 4, wherein the modifying step configures the secondversion to communicate with different computer software components.
 6. Amethod as recited in claim 1, wherein said steps (c) and (d) eachcomprise selectively loading files of objects into the correspondingruntime environment.
 7. A method as recited in claim 6, wherein saidstep (b) comprises storing the objects as Java classes and wherein saidsteps (c) and (d) each comprise executing a custom class loader forselectively loading Java classes of the corresponding version into aJava virtual machine running on the integration server.
 8. A method asrecited in claim 1, wherein said step (a) comprises using an objectoriented modeling environment to define business processes andconnections therebetween to create an integration model.
 9. A method asrecited in claim 1, further comprising: (e) executing the first versionof the project and the second version of the project concurrently.